home *** CD-ROM | disk | FTP | other *** search
- Doug here,
-
- > > <Does one thing (and, on the Falcon, not too well): Copies data from
- > > <one memory address to another, with the option of doing some shifts
- > > <and stuff while doing it. For some strange reasong, there are problems
- > > <blitting directly from the DSP host port.
- > >=20
- > > Why chould you blitt, via the dsp host port?? About copying data I'm
-
- > well, at the moment, the CPU has to feed data to/from the DSP... it would
- > have been nice if the CPU could just tell the blitter to feed the DSP...
-
- > > Double Bouble 2000, Tecnoball and so on..), so I do think that you
- > > can use the blitter for some good reasons in BM.
- > > Kill me if I=B4m wrong:-))
- >
- > No, youre not wrong. But there are not too many things that the blitter=20
- > can be used for in BM... Mainly copying the status bad and stuff...
-
- > Hm, even that is a bit dodgy, as the ammo/health need transparency... The
- > bar itself, yes...
-
- Nobody should be using the Blitter in BM for a good number of reasons:
-
- 1) It's slower than the CPU for almost everything except some complicated
- bitplane operations. Even then the CPU is not significantly behind.
-
- 2) The blitter locks the bus - causing big problems with mouse packets & other
- important interrupts when used for anything larger than an average sprite.
-
- 3) The blitter is no longer a reliable device. Current accelerators are forced
- to half-clock it to prevent problems when running a 20Mhz+ bus. This means slow
- blits or unreliable blits. Either way, it's can no longer be relied upon.
-
- 4) I can not think of anything we might need from the Blitter we can not do more
- easily with the CPU. Truecolour is the simplest screen format we have, and drawing
- in this mode is easier than using the Blitter anyway.
-
- If the blitter had been a parallel DMA device, then it would have been useful, but
- in it's current form it offers nothing but more problems. Let's avoid it.
-
- Doug.
-
-